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Abstract 


This document proposes a differentiated services per-domain behavior 
(PDB) whose traffic may be "starved" (although starvation is not 
strictly required) in a properly functioning network. This is in 
contrast to the Internet’s "best-effort" or "normal Internet traffic" 
model, where prolonged starvation indicates network problems. In 
this sense, the proposed PDB’s traffic is forwarded with a "lower" 
priority than the normal "best-effort" Internet traffic, thus the PDB 


is called "Lower Effort" (LE). Use of this PDB permits a network 
operator to strictly limit the effect of its traffic on "best- 
effort"/"normal" or all other Internet traffic. This document gives 


some example uses, but does not propose constraining the PDB’s use to 
any particular type of traffic. 


1. Description of the Lower Effort PDB 


This document proposes a differentiated services per-domain behavior 
[RFC3086] called "Lower Effort" (LE) which is intended for traffic of 
sufficiently low value (where "value" may be interpreted in any 
useful way by the network operator), in which all other traffic takes 
precedence over LE traffic in consumption of network link bandwidth. 
One possible interpretation of "low value" traffic is its low 
priority in time, which does not necessarily imply that it is 
generally of minor importance. From this viewpoint, it can be 
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considered as a network equivalent to a background priority for 
processes in an operating system. There may or may not be memory 
(buffer) resources allocated for this type of traffic. 


Some networks carry traffic for which delivery is considered 
optional; that is, packets of this type of traffic ought to consume 
network resources only when no other traffic is present. 
Alternatively, the effect of this type of traffic on all other 
network traffic is strictly limited. This is distinct from "best- 


effort" (BE) traffic since the network makes no commitment to deliver 
LE packets. In contrast, BE traffic receives an implied "good faith" 
commitment of at least some available network resources. This 


document proposes a Lower Effort Differentiated Services per-domain 
behavior (LE PDB) [RFC3086] for handling this "optional" traffic ina 
differentiated services domain. 


There is no intrinsic reason to limit the applicability of the LE PDB 
to any particular application or type of traffic. It is intended as 
an additional tool for administrators in engineering networks. 


Note: where not otherwise defined, terminology used in this document 
is defined as in [RFC2474]. 


2. Applicability 


A Lower Effort (LE) PDB is for sending extremely non-critical traffic 
across a DS domain or DS region. There should be an expectation that 
packets of the LE PDB may be delayed or dropped when other traffic is 
present. Use of the LE PDB might assist a network operator in moving 
certain kinds of traffic or users to off-peak times. Alternatively, 
or in addition, packets can be designated for the LE PDB when the 
goal is to protect all other packet traffic from competition with the 
LE aggregate, while not completely banning LE traffic from the 
network. An LE PDB should not be used for a customer’s "normal 
internet" traffic, nor should packets be "downgraded" to the LE PDB 
for use as a substitute for dropping packets that ought to simply be 
dropped as unauthorized. The LE PDB is expected to be applicable to 
networks that have some unused capacity at some times of day. 


This is a PDB that allows networks to protect themselves from 
selected types of traffic rather than giving a selected traffic 
aggregate preferential treatment. Moreover, it may also exploit all 
unused resources from other PDBs. 
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3. Technical Specification 
3.1. Classification and Traffic Conditioning 


There are no required traffic profiles governing the rate and bursts 
of packets beyond the limits imposed by the ingress link. It is not 
necessary to limit the LE aggregate using edge techniques since its 
PHB is configured such that packets of the aggregate will be dropped 
in the network if no forwarding resources are available. The 
differentiated services architecture [RFC2475] allows packets to be 
marked upstream of the DS domain or at the DS domain’s edge. When 
packets arrive pre-marked with the DSCP used by the LE PDB, it should 
not be necessary for the DS domain boundary to police that marking; 
further (MF) classification for such packets would only be required 
if there was some reason for the packets to be marked with a 
different DSCP. 


If there is not an agreement on a DSCP marking with the upstream 
domain for a DS domain using the LE PDB, the boundary must include a 
classifier that selects the appropriate LE target group of packets 
out of all arriving packets and steers them to a marker that sets the 
appropriate DSCP. No other traffic conditioning is required. 


3.2. PHB configuration 


Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use 
(EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] 
may be used as the PHB for the LE traffic aggregate. This document 
does not specify the exact DSCP to use inside a domain, but instead 
specifies the necessary properties of the PHB selected by the DSCP. 
If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. 


The PHB used by the LE aggregate inside a DS domain should be 
configured so that its packets are forwarded onto the node output 
link when the link would otherwise be idle; conceptually, this is the 
behavior of a weighted round-robin scheduler with a weight of zero. 


An operator might choose to configure a very small link share for the 
LE aggregate and still achieve the desired goals. That is, if the 
output link scheduler permits, a small fixed rate might be assigned 
to the PHB, but the behavior beyond that configured rate should be 
that packets are forwarded only when the link would otherwise be 
idle. This behavior could be obtained, for example, by using a CBQ 
[CBQ] scheduler with a small share and with borrowing permitted. A 
PHB that allows packets of the LE aggregate to send more than the 
configured rate when packets of other traffic aggregates are waiting 
for the link is not recommended. 
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If a CS PHB is used, note that this configuration will violate the 
"SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have 
a less timely forwarding than CSO. An operator’s goal of providing 
an LE PDB is sufficient cause for violating the SHOULD. If an AF PHB 
is used, it must be configured and a DSCP assigned such that it does 
not violate the "MUST" of paragraph three of section 2 of RFC 2597 
[RFC2597] which provides for a "minimum amount of forwarding 
resources". 


Attributes 


The ingress and egress flow of the LE aggregate can be measured but 
there are no absolute or statistical attributes that arise from the 
PDB definition. A particular network operator may configure the DS 
domain in such a way that a statistical metric can be associated with 
that DS domain. When the DS domain is known to be heavily congested 
with traffic of other PDBs, a network operator should expect to see 
no (or very few) packets of the LE PDB egress from the domain. When 
there is no other traffic present, the proportion of the LE aggregate 
that successfully crosses the domain should be limited only by the 
capacity of the network relative to the ingress LE traffic aggregate. 


Parameters 
None required. 

Assumptions 
A properly functioning network. 

Example uses 

o Multimedia applications [this example edited from Yoram Bernet]: 


Many network managers want to protect their networks from certain 
applications, in particular, from multimedia applications that 
typically use such non-adaptive protocols as UDP. 


Most of the focus in quality-of-service is on achieving attributes 
that are better than Best Effort. These approaches can provide 
network managers with the ability to control the amount of 
multimedia traffic that is given this improved performance with 
excess relegated to Best Effort. This excess traffic can wreak 
havoc with network resources even when it is relegated to Best 
Effort because it is non-adaptive and because it can be 
Significant in volume and duration. These characteristics permit 
it to seize network resources, thereby compromising the 
performance of other, more important applications that are 
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included in the Best Effort traffic aggregate but that use 
adaptive protocols (e.g., TCP). As a result, network managers 
often simply refuse to allow multimedia applications to be 
deployed in resource constrained parts of their network. 


The LE PDB enables a network manager to allow the deployment of 
multimedia applications without losing control of network 
resources. A limited amount of multimedia traffic may (or may 
not) be assigned to PDBs with attributes that are better than Best 
Effort. Excess multimedia traffic can be prevented from wreaking 
havoc with network resources by forcing it to the LE PDB. 


o For Netnews and other "bulk mail" of the Internet. 


o For "downgraded" traffic from some other PDB when this does not 
violate the operational objectives of the other PDB or the overall 
network. As noted in section 2, LE should not be used for the 
general case of downgraded traffic, but may be used by design, 
e.g., when multicast is used with a value-added DS-service and 
consequently the Neglected Reservation Subtree problem [NRS] 
arises. 


o For content distribution, peer-to-peer file sharing traffic, and 
the like. 


o For traffic caused by world-wide web search engines while they 
gather information from web servers. 


Experiences 


The authors solicit further experiences for this section. Results 
from simulations are presented and discussed in Appendix A. 


Security Considerations for LE PDB 


There are no specific security exposures for this PDB. See the 
general security considerations in [RFC2474] and [RFC2475]. 


History of the LE PDB 


The previous name of this PDB, "bulk handling", was loosely based on 
the United States’ Postal Service term for very low priority mail, 
sent at a reduced rate: it denotes a lower-cost delivery where the 
items are not handled with the same care or delivered with the same 
timeliness as items with first-class postage. Finally, the name was 
changed to "lower effort", because the authors and other DiffServ 
Working Group members believe that the name should be more generic in 
order to not imply constraints on the PDB’s use to a particular type 
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of traffic (namely that of bulk data). 


The notion of having something "lower than Best Effort" was raised in 
the Diffserv Working Group, most notably by Roland Bless and Klaus 
Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet 
for enterprise multimedia applications. One of its first 
applications was to re-mark packets within multicast groups [NRS]. 
Therefore, previous discussions centered on the creation of a new 
PHB. However, the original authors (Brian Carpenter and Kathleen 
Nichols) believe this is not required and this document was written 
to specifically explain how to get less than Best Effort without a 
new PHB. 
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Appendix A. Experiences from a Simulation Model 


The intention of this appendix is to show that a Lower Effort PDB 
with a behavior as described in this document can be realized with 
different implementations and PHBs respectively. Overall, each of 
these variants show the desired behavior but also show minor 
differences in certain traffic load situations. This comparison 
could make the choice of a realization variant interesting for a 
network operator. 


ALe Simulation Environment 


The small DiffServ domain shown in Figure 1 was used to simulate the 
LE PDB. There are three main sources of traffic (S1-S3) depicted on 
the left side of the figure. Source S1 sends five aggregated TCP 
flows (A1-A5) to the receivers R1-R5 respectively. Each aggregated 
flow Ax consists of 20 TCP connections, where each aggregate 
experiences a different round trip time between 10ms and 250ms. 

There are two sources of bulk traffic. Bl consists of 100 TCP 
connections sending as much data as possible to R6 and B2 is a single 
UDP flow also sending as much as possible to R7. 


R1 
/ 
/-R2 
. ; / 
S1==**=>[BR1] [BR4]==**==>---R3 
\\ Jef? % \ 
\\ // ; \-R4 
kk k*k 3 \ 
\\ // 3 R5 
A // 
S$2=4++=>[BR2]-++-[IR1] k x==++ oe [IR2] 
(Bulk) : // \\ 
// 2: 
2: \\ 
// ++ . 
AA NAs 
S3==: : ==> [BR3] [BR5] ==++==>R6 


Figure 1: A DiffServ domain with different flows 
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In order to show the benefit of using the LE PDB instead of the 
normal Best Effort (BE) PDB [RFC3086], different scenarios are used: 


A) Bl and B2 are not present, i.e., the "normal" situation without 
bulk data present. A1-A5 use the BE PDB. 


B) Bl and B2 use the BE PDB for their traffic, too. 


C) Bl and B2 use LE PDB for their traffic with different PHB 


implementations: 
1) PHB with Priority Queueing (PQ) 
2) PHB with Weighted Fair Queueing (WFQ) 
3) PHB with Weighted RED (WRED) 
4) PHB with WFQ and RED 


C1) represents the case where there are no allocated resources for 
the LE PDB, i.e., LE traffic is only forwarded if there are unused 


resources. In scenarios C2)-C4), a bandwidth share of 10% has been 
allocated for the LE PDB. RED parameters were set to w_q=0.1 and 
max_p=0.2. In scenario C2), two tail drop queues were used for BE 


and LE and WFQ scheduling was set up with a weight of 9:1 for the 
ratio of BE:LE. In scenario C3), a total queue length of 200000 
bytes was used with the following thresholds: min_th_BE=19000, 
max_th_BE=63333, min_th_LE=2346, max_th=7037. WRED allows to mark 
packets with BE or LE within the same microflow (e.g., letting 
applications pre-mark packets according to their importance) without 
causing a reordering of packets within the microflow. In scenario 
C4), each queue had a length of 50000 bytes with the same thresholds 
of min_th=18000 and max_th=48000 bytes. WFQ parameters were the same 
as in C2). 


The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, 
thus creating the bottleneck in the network for the following 
situations. In all situations, the 20 TCP connections within each 
aggregated flow Ax (flowing from S1 to Rx) used the Best Effort PDB. 
Sender S2 transmitted bulk flow B1 (consisting of 100 TCP connections 
to R6) with an aggregated rate of 550 kbit/s, whereas the UDP sender 
S3 transmitted with a rate of 50 kbit/s. 
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The following four different situations with varying traffic load for 
the Ax flows (at application level) were simulated. 


Situation | T, -r || rier ||. ae || 
---------------------------- 4+------4------4+------+4------ | 
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 | 
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 | 
Sender Rate S3 [kbit/s] | 50| 50| 50| 50| 
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 | 
Best Effort Load (S1) 100% 90% 150% 67% 

Total load for link IR1->IR2| 150% | 140% | 200% | 117% | 


In situation I, there are no unused resources left for the Bl and B2 
flows. In situation II, there is a residual bandwidth of 10% of the 
bottleneck link between IR1 and IR2. In situation III, the traffic 
load of A1l-A5 is 50% higher than the bottleneck link capacity. In 
situation IV, A1-A5 consume only 2/3 of the bottleneck link capacity. 
B1 and B2 require together 50% of the bottleneck link capacity. 


The simulations were performed with the freely available discrete 
event simulation tool OMNeT++ and a suitable set of QoS mechanisms 
[SimKIDS]. Results from the different simulation scenarios are 
discussed in the next section. 


A.2. Simulation Results 


QoS parameters listed in the following tables are averaged over the 
first 160s of the transmission. Results of situation I are shown in 
Figure 2. When the BE PDB is used for transmission of bulk flows B1 
and B2 in case B), one can see that flows A1-A5 throttle their 
sending rate to allow transmission of bulk flows Bl and B2. In case 
C1), not a single packet is transmitted to the receiver because all 
packets get dropped within IR1, thereby protecting Ax flows from Bx 
flows. In case C2), Bl and B2 consume all resources up to the 
configured limit of 10% of the link bandwidth, but not more. C3) 
also limits the share of B1 and B2 flows, but not as precisely as 
with WFQ. C4) shows slightly higher packet losses for Ax flows due 
to the active queue management. 
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SeSasee parcie sates HSS Spe Se SS 
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Results of situation II are shown in Figure 3. In case Cl), LE 
traffic gets exactly the 10% residual bandwidth that is not used by 
the Ax flows. Cases C2) and C4) show similar results compared to 


C1), whereas case C3) also drops packets from flows A1-A5 due to 
active queue management. 


+—------------------------- +-------- +----------------------------------- + 
| | | eT Transfer with PDB: 
QoS Parameter ire | C) Lower Effort 
No are TR 1) 2) 3) 4) 
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 
Foetet na e trt +------ trant +------ #¢=s5555 Fersan + 
| | Al | 216 | 193 | 216 | 216 | 211 | 216 | 
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 | 
| | a3 | 216 | 86 | 216 | 216 | 210 | 216 | 
Throughput A4 215 121 215 245 217 215 | 
| [kbit/s] | A5 | 215 101 215 215 210 215 
| | Bl | - | 488 | 83 | 83 | 114 | 84 | 
| | B2 | - | 39 | 39 | 39 | 33] 38 | 
4+---------------- +-------- +-------- +------ +------ +------ +------ +------- + 
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 | 
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 | 
A A pateta n E +------ ranma +=- +----+-+------- + 
| | Al | o| 9.4 | o | o| 1.8 | o | 
| | 42 | o | 14.6 | o | o| 2.0 | oO | 
| | a3 | o | 22.4 | o | O 2s | o | 
| Paket Loss | a4 | o | 15.5 | o | o | 1.8 | o | 
[3] A5 Ò iTA 0 0 1.9 0 
| B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 | 
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 | 
A E EEN +-------- +-------- +------ +------ +------ +------ +------- + 
| Total Packet | normal | 4 -14:97 | o | O- |) Ee )\| o | 
| Loss Rate [%] | bulik | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 | 
+—---------------- +-------- +-------- +------ +------ +------ +------ +------- + 
| Transmitted | | | | | | | | 
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 | 
a E E E asss +-------- +------ +------ +------ =se +------- + 


Figure 3: Situation II - Best Effort traffic uses 90% of the 
available bandwidth 
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Results of simulations for situation III are depicted in Figure 4. 
Due to overload caused by flows A1-A5, packets get dropped in all 
cases. Bulk flows Bl and B2 nearly get their maximum throughput in 
case B). As one would expect, in case Cl) all packets from Bl and B2 
are dropped, in cases C2) and C4) resource consumption of bulk data 
is limited to the configured share of 10%. Again the WRED 
implementation in C3) is not as accurate as the WFQ variants and lets 
more BE traffic pass through IR1. 


tase SSoee SSS sot ease SaaS tH SoSH SS Pepe eee Se SS eee See eS Sa eSS + 
| | | Bulk Transfer with PDB: 
| QoS Parameter | A) | B) | C) Lower Effort 
| |No bulk | Best | 1) 2) 3) 4) | 
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 
Sl +-------- +-------- +------ +------ resá {osis asss + 
Al 303 136 241 298 244 276 
A2 316 234 286 299 240 219 
| | a3 | 251 | 140 | 287 | 259 | 236 | 225 | 
| Throughput | a4 | 168 | 84 | 252 | 123 | 209 | 219 | 
| [kbit/s] | as | 159 | 82 | 132 | 101 | 166 | 141 | 
| | Bl | - | 483 | o {| 83 | 73 | 83 | 
| | B2 | - | 41 | o| 38 | 31 | 38 | 
+—S5S55553-55555 +-------- tanmen +------ terei +------ +------ +------- + 
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 | 
| [kbit/s] | buik | - | 524 | 0: |, 2i] tosi a2] 
S E ssSss= şr +-------- +------ +------ +------ +------ +5SS5sH5 + 
| | Al | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 | 
A2 8.5 | 13.6 8.4 9.8 8.1 14.5 
|) ae |) ee hen orlare] ae |: aa | 
| Paket Loss | <A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 | 
| [%] | a5 | 1228 || LIO 0S: 193.7 a83 A43: 
| | Bl | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 | 
| | B2 | =a | ERSA TOO | 22a ee BTT B28" | 
4+---------------- +-------- +-------- +------ +------ +------ +------ +------- + 
| Total Packet | normal | £04, | ETS ||) £08. [22.24 sr, TIA] 
| Loss Rate [%] | bulik | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 | 
4+---------------- +aSSHa=Hs frcsa +------ +------ +asSSs= tosses pasm + 
| Transmitted | | | | | | | | 
| Data [MByte] | normai | -22707 | i26 220- 202 | 2076 -203| 
A a A sos. þri toe SSeS +------ +------ +------ +------ a + 


Figure 4: Situation III - Best Effort traffic load is 150% 
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In situation IV, 33% or 400 kbit/s are not used by Ax flows and the 
results are listed in Figure 5. In case B) where bulk data flows B1 
and B2 use the BE PDB, packets of Ax flows are dropped, whereas in 
cases C1)-C4) flows Ax are protected from bulk flows Bl and B2. 
Therefore, by using the LE PDB for Bx flows, the latter get only the 
residual bandwidth of 400 kbit/s but not more. Packets of Ax flows 
are not affected by Bx traffic in these cases. 


+------------------------- +-------- ta Se T - S + 
| | Bulk Transfer with PDB: | 
QoS Parameter | A) | B) | C) Lower Effort 
|No bulk | Best | 1) 2) 3) 4) | 
Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 
See SS SSeS el S= Sa aa a a a a aa ae E 
| Al | 160 | 140 | 160 | 160 | 160 | 160 | 
| A2 | 160 | 124 | 160 | 160 | 160 | 160 | 
A3 160 112 160 160 160 160 
Throughput | a4 | 160 | 137 | 160 | 160 | 159 | 160 | 
[kbit/s] | a5 | 159 | 135 | 159 | 159 | 159 | 159 | 
| Bl | - | 509 | 361 | 362 | 364 | 362 | 
| B2 | -| 43 | 40 | 39 | 38 | 40 | 
4+---------------- +-------- +-------- +------ +------ +------ +------ +------- + 
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 | 
[kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401| 
hoe Sst SSS SSS foe a teases +------ foaren +------ +------ a + 
| Al | o| 9.2 | o | o | o | o | 
| A2 | o | 12.2 | o | o | o | o| 
| A3 | 0 | 14.0 | 0 | 0 | 0 | 0 | 
Paket Loss A4 0 9,3 0 0 0 0 
%] | a5 | o] 6.6 | o | o | oO | oO | 
| Bl | =i} TRI le algae | Dees: Il eee eae: |". alesse | 
| B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 | 
+---------------- +-------- +-------- +------ +------ +------ +------ +------- + 
Total Packet normal 0 10:52 0 0 0 0 
Loss Rate [%] bulk = 8.0 21, ..0 2457 25.0 2022 
Sa ae ae tases ses ¢oeSSeSes +------ +------ +------ prne S + 
Transmitted | | | | | | | | 
Data [MByte] | normal | tais | 1241 |) 148 | Base: | TAT DET | 
pomier +-------- foo See +------ +------ +------ +------ +------- + 


Figure 5: Situation IV - Best Effort traffic load is 67% 


In summary, all the different scenarios show that the "normal" BE 
traffic can be protected from traffic in the LE PDB effectively. 
Either no packets get through if no residual bandwidth is left (LE 
traffic is starved), or traffic of the LE PDB can only consume 
resources up to a configurable limit. 
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Furthermore, the results substantiate that mass data transfer can 
adversely affect "normal" BE traffic (e.g., 14.9% packet loss in 
situations I and II, even 10.2% in situation IV) in situations 
without using the LE PDB. 


Thus, while all presented variants of realizing the LE PDB meet the 
desired behavior of protecting BE traffic, they also show small 
differences in detail. A network operator has the opportunity to 
choose a realization method to fit the desired behavior (showing this 
is - after the proof of LE’s efficacy - the second designation of 
this appendix). For instance, if operators want to starve LE traffic 
completely in times of congestion, they could choose PQ. This causes 
LE traffic to be completely starved and not a single packet would get 
through in case of full load or overload. 


On the other hand, for network operators who want to permit some 
small amount of throughput in the LE PDB, one of the other variants 
would be a better choice. 


Referring to this, the WFQ implementation showed a slightly more 
robust behavior with PQ, but had problems with synchronized TCP 
flows. WRED behavior is highly dependent on the actual traffic 
characteristics and packet loss rates are often higher compared to 
other implementations, while the fairness between TCP connections is 
better. The combined solution of WFQ with RED showed the overall 
best behavior, when an operator’s intent is to keep a small but 
noticeable throughput in the LE PDB. 
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